In the field of data processing, software designers continually develop and release new versions of software having improved functionality relative to older versions of the software. In conventional computer systems, there are various reasons for substituting a newer version of software for an older version of software, and for substituting an older version of software for a newer version of software.
For example, when a new version of software includes improved functionality and/or improved diagnostic capabilities relative to an older version of the software, it is often desirable to replace the older version of software with the newer, improved version of software. As another example, if a spare or replacement component that has already been programmed with an older version of software is introduced into a system whose other components utilize a newer version of the software, then it may be desirable to modify the spare component to replace its older software version with the newer software version used in the other system components so that, for example, all system components are executing the same version of software.
In other instances, it may be desirable to replace a newer version of software with an older version of software. For example, if a new component that has already been programmed with a new version of software is introduced into an older system whose other components run an older version of the software, it may be desirable to modify the new component by replacing its newer version of software with the older version of software used in the other system components to, for example, ensure that all system components are executing the same version of software. As another example, if one component of a system is updated to run a newer version of software, and thereafter the system develops operational problems, then it may be desirable to change the software in that one component back to the older version that was in use before the operational problems arose.
In a distributed computer system wherein the various components can be geographically located quite remotely from one another, it is often desirable, when substituting one version of software for another version, to download the desired version of software from a remote source to a program memory in the desired destination. The download is typically executed via a connection that is otherwise used for other types of communication between the remote source and the data processor. For example, the remote source could be another data processor in the system, and the connection could be a communication bus connected between the data processors. This is illustrated in FIG. 1 wherein remote source 11 is connected by communication bus 23 to data processor 13 and performs a remote software download via bus 23 into program memory 15 of data processor 13.
FIG. 2 illustrates the effect of the remote software download of FIG. 1. More specifically, the currently executing software SWc is executed by execution portion 21 of data processor 13 until the downloaded software SWd is downloaded from the remote source 11, at which time SWd begins to be executed by execution portion 21. Because the system already provides bus 23 for communication between the remote source 11 and data processor 13, and because the geographic location of data processor 13 may make it difficult to physically or manually access data processor 13, the bus 23 is advantageously used to perform the remote software download to data processor 13.
FIGS. 3 and 4 respectively illustrate relevant portions of SWc and SWd in diagrammatic fashion. SWc and SWd are different versions of software. SWc includes a data handler portion 31 which handles data from data memory 17 of FIG. 1 differently than does the data handler portion 41 of SWd in FIG. 4. Thus, the data accessed at 33 by data handler 31 of SWc in FIG. 3 will not necessarily be compatible with the data handler 41 of SWd in FIG. 4, and the data accessed at 43 by data handler 41 of SWd will not necessarily be compatible with the data handler 31 of SWc in FIG. 3. For example, each of the different data handlers 31 and 41 of respective software versions SWc and SWd may require a different data format than the other one and/or may require a different data memory layout (or configuration) than the other one.
The accessed data in FIGS. 3 and 4 can be, for example, a database, a volatile memory such as a RAM, a non-volatile memory such as flash memory, floppy disk or hard disk, or a file format. As indicated above, SWc may require the accessed data to have a different format than is required by SWd, and SWc may require the data memory 17 to be configured differently than the memory configuration required by SWd. Thus, replacing SWc with SWd by remote download as illustrated in FIGS. 1 and 2 will often result in SWd attempting to access a data memory 17 whose data format and memory configuration is not compatible with that required by SWd.
One conventional approach to this problem is to design the original software version with a data handler that provides all possible data format and memory configuration parameters that could be needed by future versions of the software. In this manner, any version of the software would, when downloaded to replace another version, find data memory 17 having a data format and memory configuration that it requires. This is of course a very difficult task because it is virtually impossible to predict the data format and memory configuration that will be required by future versions of the software. Even if it were possible to perform this task, it would be extremely expensive to perform because of the extended amount of time necessary to predict all possible data formats and memory configurations that could be needed in the future.
Another conventional solution to the data access compatibility problem is visiting the site of data memory 17 and manually reformatting the data and reconfiguring the memory at the time that SWd is downloaded. Such manual intervention is very costly and time consuming (data memory 17 may be very remotely located), and may cause major disturbances in data flow to and from the other system components illustrated at 19 in FIG. 1.
Another conventional solution recognizes that the data handler of a newer version of software can, in most cases, handle the data format and memory configuration required by the data handlers of all previously released versions of the software. This solution is illustrated by the flow charts of FIGS. 5 and 6.
FIG. 5 illustrates the download control of SWc. Recall from FIG. 2 that SWc is executing on data processor 13 until SWd is downloaded from remote source 11. The download control portion 50 of SWc receives and stores the SWd download at 51, and awaits at 53 a command from the remote source 11 to allow SWd to begin execution. When the remote source commands execution of SWd, SWc at 55 causes data processor 13 to restart, running SWd.
FIG. 6 illustrates the download reformat portion 60 of SWd. At 61, SWd determines whether or not it supports the current database (DB) format, which in most cases it will because it is a newer version of software than SWc. Nevertheless, if SWd does not support the current database format, then SWd, which is capable of handling the SWc format of the database, simply reformats the database to its preferred format at 63. At 65, SWd determines whether or not it supports the current memory configuration, which in most causes it will because it is a newer version of software than SWc. Nevertheless, if SWd does not support the current memory configuration, it uses its capability to handle the SWc memory configuration and simply changes the configuration to its own preferred configuration at 67.
It is again emphasized that the technique, illustrated in FIGS. 5 and 6, of downloading a newer version of software and having that newer version reformat the data and reconfigure the memory as needed, only addresses the relatively minor problem of data access incompatibility when a newer version of software replaces an older version of software. On the other hand, an older version of software generally cannot handle the data format and memory configuration used by later versions of software. Thus, in situations like those described above where an older version of software replaces a newer version of software, manual intervention must occur at the site of data memory 17 in order to manually reformat the data and reconfigure the memory for compatibility with the data handler of the older version of software that has been downloaded.
Another conventional approach is to update the data handler of every existing version of software whenever a new version of software with a different data handler and different data format and data configuration requirements is released. This is of course very costly and time consuming for the software vendor. Moreover, it is difficult to get such updated software into use in all customer systems. The customer does not want to "disturb" a system more than absolutely needed, which may force the supplier to provide system components which each have a different software version pre-programmed therein but are otherwise identical. The supplier must then keep track of which software version is used by which customer, and deliver equipment with that customer's software version programmed therein in order to avoid the above-described process of replacing a newer software version with an older software version when the equipment is installed in the system. This requirement of providing various equipments with different software versions therein and keeping track of which software versions are used by which customer systems adds more complexity to production of the equipment, which is very costly and time consuming for the supplier.
It is therefore desirable to provide for remote downloading of an older version of software to replace a newer version of software wherein the data format and memory configuration provided to the older version of software is compatible with the older version of software, without need for manual intervention at the site of the data memory, without need for updating the data handler portion of every software version whenever a new software version is released, and without need to design the earliest software version such that its data handler will be compatible with the data handlers of every subsequent future version of the software.
The present invention provides for remote downloading of an older version of software to replace a newer version of software wherein the downloaded older version of software encounters a data format and memory configuration with which it is compatible. The technique of the present invention does not require manual intervention at the site of the data memory, does not require updating the data handler of every existing version of software whenever a new version of software is released, and does not require the data handler of the first version of software to meet all data handling, data formatting and memory configuration needs of every subsequent version of the software released in the future.